FishMarket 1.0/FishMarket v1.0.iso/fishies/301-325/disk_313/uucp/uucp1.lzh/man/Standards

Text File | 1989-11-03 | 90KB | 2,381 lines

         Standard for Interchange of USENET Messages

                Mark R. Horton




      1.  Introduction              Introduction              Introduction              Introduction

      This document defines the standard format for  interchange
      of Network News articles among USENET sites.    It describes
      the format for  articles  themselves,  and  gives  partial
      standards for transmission of news.  The news transmission
      is not entirely standardized in order to give a good    deal
      of   flexibility   to   the  individual  hosts  to  choose
      transmission hardware and software, whether to batch news,
      and so on.

      There are five sections to  this  document.    Section  two
      section  defines  the  format.   Section three defines the
      valid control messages.  Section four specifies some valid
      transmission    methods.  Section five describes the overall
      news propagation algorithm.


      2.  Article Format              Article Format              Article Format              Article Format

      The primary consideration in choosing an article format is
      that    it  fit  in with existing tools as well as possible.
      Existing tools include both implementations  of  mail  and
      news.   (The  notesfiles  system  from  the  University of                        __________
      Illinois is considered a news implementation.) A  standard
      format for mail messages has existed for many years on the
      ARPANET, and this  format  meets  most  of  the  needs  of
      USENET.    Since   the   ARPANET   format  is  extensible,
      extensions to meet the  additional  needs  of  USENET  are
      easily  made    within the ARPANET standard.  Therefore, the
      rule is adopted that all  USENET  news  articles  must  be
      formatted as valid ARPANET mail messages, according to the
      ARPANET  standard  RFC  822.     This    standard   is    more
      restrictive  than the ARPANET standard, placing additional
      requirements on each article and forbidding use of certain
      ARPANET  features.   However, it should always be possible
      to use a tool expecting an ARPANET message  to  process  a
      news    article.   In  any  situation  where  this  standard
      conflicts with the ARPANET standard,    RFC  822  should  be
      considered correct and this standard in error.

      An example message is included to illustrate the fields.

















                    - 2 -



           Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
           Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
           Path: cbosgd!mhuxj!mhuxt!eagle!jerry
           From: [e-mail] (Jerry Schwarz)
           Newsgroups: net.general
           Subject: Usenet Etiquette -- Please Read
           Message-ID: <[e-mail]>
           Date: Friday, 19-Nov-82 16:14:55 EST
           Followup-To: net.news
           Expires: Saturday, 1-Jan-83 00:00:00 EST
           Date-Received: Friday, 19-Nov-82 16:59:30 EST
           Organization: Bell Labs, Murray Hill

           The body of the article comes here, after a blank line.

      Here is an example of a message in the old format  (before
      the  existence  of this standard).  It is recommended that
      implementations also accept articles    in  this  format  to
      ease upward conversion.

           From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz)
           Newsgroups: net.general
           Title: Usenet Etiquette -- Please Read
           Article-I.D.: eagle.642
           Posted: Fri Nov 19 16:14:55 1982
           Received: Fri Nov 19 16:59:30 1982
           Expires: Mon Jan  1 00:00:00 1990

           The body of the article comes here, after a blank line.

      Some news systems transmit news in the ``A'' format, which
      looks like this:

           Aeagle.642
           net.general
           cbosgd!mhuxj!mhuxt!eagle!jerry
           Fri Nov 19 16:14:55 1982
           Usenet Etiquette - Please Read
           The body of the article comes here, with no blank line.

      An article consists of several header lines, followed by a
      blank  line,    followed  by  the  body of the message.  The
      header lines consist of a keyword, a colon, a  blank,  and
      some    additional  information.   This  is  a subset of the
      ARPANET standard, simplified to allow simpler software  to
      handle  it.    The  ``from''  line may optionally include a
      full name, in the format above, or use the  ARPANET  angle
      bracket syntax.  To keep the implementations simple, other
      formats (for example, with part  of  the  machine  address
      after the close parenthesis) are not allowed.  The ARPANET
      convention of continuation header lines (beginning with  a











                    - 3 -



      blank or tab) is allowed.

      Certain  headers  are  required,   certain   headers     are
      optional.   Any unrecognized headers are allowed, and will
      be passed through unchanged.     The  required    headers  are
      Relay-Version,  Posting-Version,  From,  Date, Newsgroups,
      Subject,  Message-ID,  Path.     The  optional    headers  are
      Followup-To,    Date-Received,    Expires,  Reply-To,  Sender,
      References, Control, Distribution, Organization.

      2.1  Required Headers               Required Headers               Required Headers               Required Headers

      2.1.1  Relay-Version    This header line shows    the  version                 _____________
      of  the  program  responsible for the transmission of this
      article over the immediate link, that is, the program that
      is  relaying the article from the next site.    For example,
      suppose site A sends an article to  site  B,    and  site  B
      forwards  the  article  to  site  C.     The  message  being
      transmitted from A to B would have a Relay-Version  header
      identifying  the  program  running  on  A, and the message
      transmitted from B to C would identify the program running
      on  B.  This header can be used to interpret older headers
      in an upward compatible way.    Relay-Version must always be
      the  first  in  a message; thus, all articles meeting this
      standard will begin with an upper case  ``R''.   No  other
      restrictions are placed on the order of header lines.

      The line contains two  fields,  separated  by  semicolons.
      The fields are the version and the full domain name of the
      site.  The version should identify the system program used
      (e.g.,  ``B'')  as  well  as  a version number and version
      date.  For example, the header line might contain

           Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP

      This header should not be passed on to  additional  sites.
      A  relay  program,  when  passing  an  article  on, should
      include only its own Relay-Version, not the  Relay-Version
      of  some other site.    (For upward compatibility with older
      software, if a Relay-Version is found in a header which is
      not the first line, it should be assumed to be moved by an
      older version of news and deleted.)

      2.1.2  Posting-Version    This   header   identifies     the                 _______________
      software  responsible  for  entering this message into the
      network.  It has the same  format  as  Relay-Version.   It
      will    normally  identify  the same site as the Message-ID,
      unless the posting site is serving  as  a  gateway  for  a
      message  that  already  contains a message ID generated by
      mail.  (While it is permissible for a gateway  to  use  an
      externally  generated message ID, the message ID should be











                    - 4 -



      checked to ensure it conforms to this standard and to  RFC
      822.)

      2.1.3  From  The From line contains the electronic mailing                 ____
      address  of  the  person who sent the message, in the ARPA
      internet syntax.  It may optionally also contain the    full
      name    of  the person, in parentheses, after the electronic
      address.  The electronic address is the same as the entity
      responsible for originating the article, unless the Sender
      header is present, in which case the From header might not
      be  verified.   Note    that  in  all site and domain names,
      upper  and  lower  case  are    considered  the  same,    thus
      [e-mail],  [e-mail],    and [e-mail]
      are all equivalent.  User names may or  may  not  be    case
      sensitive,   for   example,    [e-mail]  might  be
      different from [e-mail].  Programs  should  avoid
      changing  the case of electronic addresses when forwarding
      news or mail.

      RFC 822 specifies that all text in parentheses  is  to  be
      interpreted as a comment.  It is common in ARPANET mail to
      place the full name of the user in a comment at the end of
      the  From  line.   This  standard  specifies    a more rigid
      syntax.  The full name is not considered a comment, but an
      optional part of the header line.  Either the full name is
      omitted, or it appears in parentheses after the electronic
      address  of  the person posting the article, or it appears
      before an electronic address enclosed in  angle  brackets.
      Thus, the three permissible forms are:

           From: [e-mail]
           From: [e-mail] (Mark Horton)
           From: Mark Horton <[e-mail]>

      Full names may contain any printing ASCII characters    from
      space through tilde, with the exceptions that they may not
      contain parentheses ``(''  or  ``)'',  or  angle  brackets
      ``<''  or ``>''.  Additional restrictions may be placed on
      full names  by  the  mail  standard,    in  particular,  the
      characters  comma  ``,'', colon ``:'', and semicolon ``;''
      are inadvisable in full names.

      2.1.4  Date  The Date line (formerly  ``Posted'')  is  the                 ____
      date,  in  a    format    that  must be acceptable both to the
      ARPANET and to the getdate routine, that the    article  was
      originally  posted  to  the  network.   This    date remains
      unchanged as the  article  is  propagated  throughout  the
      network.  One format that is acceptable to both is

           Weekday, DD-Mon-YY HH:MM:SS TIMEZONE












                    - 5 -



      Several examples of  valid  dates  appear  in  the  sample
      article above.  Note in particular that ctime format:

           Wdy Mon DD HH:MM:SS YYYY

      is not acceptable because it is not a valid ARPANET  date.             ___
      However, since older software still generates this format,
      news implementations are encouraged to accept this  format
      and translate it into an acceptable format.

      The contents of the TIMEZONE field is currently subject to
      revision.   Eventually,  we  hope  to  accept all possible
      worldwide time zone  abbreviations,  including  the  usual
      American  zones  (PST, PDT, MST, MDT, CST, CDT, EST, EDT),
      the    other    North    American   zones   (Bering   through
      Newfoundland),  European  zones,  Australian zones, and so
      on.  Lacking a complete list at present (and unsure if  an
      unambiguous    list   exists),   authors  of  software  are
      encouraged to keep this code flexible, and  in  particular
      not  to  assume  that  time  zone  names are exactly three
      letters long.   Implementations  are    free  to  edit    this
      field,  keeping  the    time the same, but changing the time
      zone (with an appropriate adjustment  to  the  local  time
      shown) to a known time zone.

      2.1.5  Newsgroups  The  Newsgroups  line  specifies  which                 __________
      newsgroup  or newsgroups the article belongs in.  Multiple
      newsgroups  may  be  specified,  separated  by  a   comma.
      Newsgroups  specified  must  all  be the names of existing
      newsgroups, as no new newsgroups will be created by simply
      posting to them.

      Wildcards (e.g., the word ``all'') are never allowed in  a
      Newsgroups  line.  For example, a newsgroup ``net.all'' is
      illegal, although a newsgroup name  ``net.sport.football''
      is permitted.

      If an article is received with a Newsgroups  line  listing
      some    valid newsgroups and some invalid newsgroups, a site
      should  not  remove  invalid    newsgroups  from  the  list.
      Instead,  the  invalid  newsgroups should be ignored.  For
      example,  suppose  site  A  subscribes  to   the   classes
      ``btl.all''  and  ``net.all'', and exchanges news articles
      with site B,    which  subscribes  to  ``net.all''  but  not
      ``btl.all''.    Suppose   A   receives   an  article  with
      ``Newsgroups: net.micro,btl.general''.   This  article  is
      passed  on  to  B because B receives net.micro, but B does
      not receive btl.general.  A must leave the Newsgroup    line
      unchanged.   If  it  were  to  remove ``btl.general'', the
      edited header could  eventually  reenter  the  ``btl.all''
      class,  resulting in an article that is not shown to users











                    - 6 -



      subscribing  to  ``btl.general''.   Also,  followups  from
      outside ``btl.all'' would not be shown to such users.

      2.1.6  Subject   The    Subject  line  (formerly  ``Title'')                 _______
      tells  what the article is about.  It should be suggestive
      enough of the contents of the article to enable  a  reader
      to  make  a  decision whether to read the article based on
      the  subject    alone.     If  the  article  is  submitted  in
      response  to another article (e.g., is a ``followup'') the
      default subject should  begin  with  the  four  characters
      ``Re:  ''  and the References line is required.  (The user
      might wish to edit the subject of the  followup,  but  the
      default should begin with ``Re: ''.)

      2.1.7  Message-ID  The Message-ID line gives the article a                 __________
      unique  identifier.  The same message ID may not be reused
      during the lifetime of any article with the  same  message
      ID.    (It  is recommended that no message ID be reused for
      at least two years.) Message ID's have the syntax

           "<" "string not containing blank or >" ">"

      In order to conform to RFC 822, the Message-ID  must    have
      the format

           "<" "unique" "@" "full domain name" ">"

      where ``full domain name'' is the full name of the host at
      which  the article entered the network, including a domain
      that host is in, and unique  is  any    string    of  printing
      ASCII  characters,  not  including  "<", ">", or "@".  For
      example,  the  "unique"   part   could   be   an   integer
      representing    a  sequence number for articles submitted to
      the network, or a short string derived from the  date  and
      time    the article was created.  For example, valid message
      ID for an article submitted from  site  ucbvax  in  domain
      Berkeley.ARPA   would   be  "<[e-mail]>".
      Programmers are urged not to make  assumptions  about  the
      content  of  message    ID  fields  from other hosts, but to
      treat them as unknown character strings.  It is not  safe,
      for  example, to assume that a message ID will be under 14
      characters,  nor  that  it  is  unique  in  the  first  14
      characters.

      The angle brackets are considered part of the message  ID.
      Thus,  in  references  to  the  message  ID,    such  as the
      ihave/sendme    and  cancel  control  messages,  the   angle
      brackets  are  included.   White  space  characters (e.g.,
      blank and tab) are not  allowed  in  a  message  ID.     All
      characters  between  the  angle  brackets must be printing
      ASCII characters.











                    - 7 -



      2.1.8  Path  This line shows the path the article took  to                 ____
      reach  the  current  system.     When  a system forwards the
      message, it should add its own name to the list of systems
      in  the  Path  line.     The  names  may be separated by any
      punctuation      character    or     characters,    thus
      ``cbosgd!mhuxj!mhuxt'',   ``cbosgd,  mhuxj,  mhuxt'',  and
      ``@cbosgd.uucp,@mhuxj.uucp,@mhuxt.uucp''     and      even
      ``teklabs,   zehntel,   sri-unix@cca!decvax''   are  valid
      entries.  (The latter path indicates a message that passed
      through  decvax,  cca,  sri-unix, zehntel, and teklabs, in
      that order.) Additional names should    be  added  from  the
      left,  for  example,    the  most recently added name in the
      third example was ``teklabs''.  Letters,  digits,  periods
      and  hyphens    are  considered  part  of  site names; other
      punctuation, including blanks, are considered separators.

      Normally, the rightmost name    will  be  the  name  of  the
      originating  system.     However,  it is also permissible to
      include an extra entry on the right, which is the name  of
      the  sender.     This is for upward compatibility with older
      system.

      The Path line is not used for replies, and should  not  be
      taken  as  a    mailing address.  It is intended to show the
      route the message  travelled    to  reach  the    local  site.
      There  are  several  uses for this information.  One is to
      monitor USENET routing for performance  reasons.   Another
      is  to  establish  a path to reach new sites.  Perhaps the
      most important is to cut down on redundant USENET  traffic
      by failing to forward a message to a site that is known to
      have already received it.   In  particular,  when  site  A
      sends  an article to site B, the Path line includes ``A'',
      so that site B will not immediately send the article    back
      to  site  A.     The  site  name  each site uses to identify
      itself should be  the  same  as  the    name  by  which  its
      neighbors  know  it,    in  order  to make this optimization
      possible.

      A site adds its own name to the front of a  path  when  it
      receives  a message from another site.  Thus, if a message
      with path A!X!Y!Z is passed from site A to site B, B    will
      add  its own name to the path when it receives the message
      from A, e.g., B!A!X!Y!Z.  If B then passes the message  on
      to  C,  the  message    sent  to  C  will  contain  the path
      B!A!X!Y!Z, and when C receives it, C    will  change  it  to
      C!B!A!X!Y!Z.

      Special upward compatibility note: Since the From, Sender,
      and  Reply-To lines are in internet format, and since many
      USENET  sites  do  not  yet  have   mailers    capable   of
      understanding  internet  format,  it would break the reply











                    - 8 -



      capability to completely sever the connection between  the
      Path    header    and  the  reply  function.   Thus, sites are
      required to continue to keep the Path line  in  a  working
      reply  format  as much as possible, until January 1, 1984.
      It is recognized that the path is not always a valid reply
      string in older implementations, and no requirement to fix
      this problem is placed on implementations.   However,  the
      existing  convention of placing the site name and an ``!''
      at the front of the path, and of starting  the  path    with
      the  site  name,  an    ``!'',  and the user name, should be
      maintained at least until 1984.

      2.2  Optional Headers               Optional Headers               Optional Headers               Optional Headers

      2.2.1  Reply-To  This line has the same  format  as  From.                 ________
      If present, mailed replies to the author should be sent to
      the name given here.    Otherwise, replies are mailed to the
      name    on the From line.  (This does not prevent additional
      copies from being sent to recipients named by the replier,
      or  on  To  or  Cc lines.) The full name may be optionally
      given, in parentheses, as in the From line.

      2.2.2  Sender  This field is present only if the submitter                 ______
      manually enters a From line.    It is intended to record the
      entity responsible  for  submitting  the  article  to  the
      network,  and  should  be  verified by the software at the
      submitting site.

      For example, if John Smith is visiting CCA and  wishes  to
      post    an  article to the network, using friend Sarah Jones
      account, the message might read

           From: [e-mail] (John Smith)
           Sender: [e-mail] (Sarah Jones)

      If a gateway    program  enters  a  mail  message  into  the
      network at site sri-unix, the lines might read

           From: [e-mail]
           Sender: [e-mail]

      The primary purpose of this field is to be able  to  track
      down    articles to determine how they were entered into the
      network.  The  full  name  may  be  optionally  given,  in
      parentheses, as in the From line.

      2.2.3  Followup-To  This  line  has  the  same  format  as                 ___________
      Newsgroups.    If  present,  follow-up  articles  are to be
      posted to the newsgroup(s) listed here.  If this  line  is
      not  present,  followups  are  posted  to the newsgroup(s)
      listed in the Newsgroups line, except  that  followups  to











                    - 9 -



      ``net.general'' should instead go to ``net.followup''.

      2.2.4  Date-Received    This line (formerly ``Received'') is                 _____________
      in  a  legal    USENET date format.  It records the date and
      time that the article was  first  received  on  the  local
      system.   If    this  line  is    present  in an article being
      transmitted from one host to another, the  receiving    host
      should  ignore  it  and  replace it with the current date.
      Since this field is intended for local use only,  no    site
      is  required    to support it.    However, no site should pass
      this field on to another site unchanged.

      2.2.5  Expires  This line,  if  present,  is    in  a  legal                 _______
      USENET  date    format.  It specifies a suggested expiration
      date for the article.  If not present, the  local  default
      expiration date is used.

      This field is intended to be used  to  clean    up  articles
      with    a  limited usefulness, or to keep important articles
      around for longer than  usual.   For    example,  a  message
      announcing  an  upcoming  seminar could have an expiration
      date the day after the seminar, since the message  is  not
      useful  after the seminar is over.  Since local sites have
      local  policies  for    expiration  of    news  (depending  on
      available disk space, for instance), users are discouraged
      from providing expiration dates for articles unless  there
      is  a  natural  expiration date associated with the topic.
      System software should  almost  never  provide  a  default
      Expires line.  Leave it out and allow local policies to be
      used unless there is a good reason not to.

      2.2.6  References  This field lists the  message  ID's  of                 __________
      any articles prompting the submission of this article.  It
      is required for all follow-up articles, and forbidden when
      a new subject is raised.  Implementations should provide a
      follow-up command, which allows a user to post a follow-up
      article.   This  command  should  generate  a Subject line
      which is the same as the original article, except that  if
      the original subject does not begin with ``Re: '' or ``re:
      '', the four characters ``Re: '' are inserted  before  the
      subject.   If  there is no References line on the original
      header, the References line should contain the message  ID
      of  the  original  article (including the angle brackets).
      If the original article does have a References  line,  the
      followup  article should have a References line containing
      the text of the original References line, a blank, and the
      message ID of the original article.

      The purpose of the References header is to allow  articles
      to  be  grouped  into  conversations by the user interface
      program.  This allows conversations within a newsgroup  to











                    - 10 -



      be  kept  together,  and  potentially users might shut off
      entire conversations without unsubscribing to a newsgroup.
      User    interfaces  may not make use of this header, but all
      automatically  generated  followups  should  generate  the
      References line for the benefit of systems that do use it,
      and manually generated followups (e.g. typed in well after
      the  original  article  has  been  printed by the machine)
      should be encouraged to include them as well.

      2.2.7  Control  If an article contains a Control line, the                 _______
      article  is  a control message.  Control messages are used
      for communication among USENET host machines,  not  to  be
      read    by  users.   Control messages are distributed by the
      same newsgroup mechanism as ordinary messages.   The    body
      of the Control header line is the message to the host.

      For  upward  compatibility,  messages   that     match     the
      newsgroup   pattern    ``all.all.ctl''   should   also   be
      interpreted as control messages.  If no Control: header is
      present  on  such  messages,    the  subject  is used as the
      control message.  However, messages on newsgroups matching
      this pattern do not conform to this standard.

      2.2.8  Distribution    This  line  is    used  to  alter  the                 ____________
      distribution scope of the message.  It has the same format
      as the Newsgroups  line.   User  subscriptions  are  still
      controlled  by  Newsgroups, but the message is sent to all
      systems subscribing to the newsgroups on the    Distribution
      line instead of the Newsgroups line.    Thus, a car for sale
      in New Jersey might have headers including

           Newsgroups: net.auto,net.wanted
           Distribution: nj.all

      so that  it  would  only  go    to  persons  subscribing  to
      net.auto  or    net.wanted within New Jersey.  The intent of
      this header is to further restrict the distribution  of  a
      newsgroup, not to increase it.  A local newsgroup, such as
      nj.crazy-eddie, will probably not be propagated  by  sites
      outside  New    Jersey    that do not show such a newsgroup as
      valid.  Wildcards in newsgroup names in  the    Distribution
      line are allowed.  Followup articles should default to the
      same Distribution line as the original  article,  but  the
      user    can change it to a more limited one, or escalate the
      distribution if it was originally restricted    and  a    more
      widely distributed reply is appropriate.

      2.2.9  Organization  The text of  this  line    is  a  short                 ____________
      phrase  describing  the  organization  to which the sender
      belongs, or to which the machine belongs.  The  intent  of
      this    line  is  to  help  identify  the person posting the











                    - 11 -



      message, since site names are often cryptic enough to make
      it  hard  to    recognize the organization by the electronic
      address.


      3.  Control Messages              Control Messages              Control Messages              Control Messages

      This section lists the control messages currently defined.
      The  body  of  the  Control header is the control message.
      Messages are a sequence of zero or more  words,  separated
      by  white  space  (blanks or tabs).  The first word is the
      name    of  the  control  message,   remaining     words     are
      parameters  to  the  message.  The remainder of the header
      and the body of the message are also potential parameters;
      for  example,  the  From  line might suggest an address to
      which a response is to be mailed.

      Implementors    and  administrators  may  choose  to   allow
      control  messages  to  be automatically carried out, or to
      queue  them  for  manual  processing.   However,  manually
      processed messages should be dealt with promptly.

      3.1  Cancel               Cancel               Cancel               Cancel

           cancel <message ID>

      If an article with the given message ID is present on  the
      local  system,  the  article is cancelled.  This mechanism
      allows a user to cancel an article after the    article  has
      been distributed over the network.

      Only the author of the article or the local super user  is
      allowed  to  use  this  message.  The verified sender of a
      message is the Sender  line,    or  if    no  Sender  line  is
      present, the From line.  The verified sender of the cancel
      message must be the same as  either  the  Sender  or    From
      field  of  the original message.  A verified sender in the
      cancel message is allowed to match an unverified  From  in
      the original message.

      3.2  Ihave/Sendme               Ihave/Sendme               Ihave/Sendme               Ihave/Sendme

           ihave <message ID list> <remotesys>
           sendme <message ID list> <remotesys>

      This message is part    of  the  ``ihave/sendme''  protocol,
      which  allows  one  site  (say ``A'') to tell another site
      (``B'') that a particular message has been received on  A.
      Suppose  that site A receives article ``ucbvax.1234'', and
      wishes to transmit the article to site  B.   A  sends  the
      control  message  ``ihave  ucbvax.1234  A''  to site B (by











                    - 12 -



      posting it to newsgroup ``to.B'').  B  responds  with  the
      control  message  ``sendme  ucbvax.1234  B'' (on newsgroup
      to.A) if it has not already received    the  article.    Upon
      receiving the Sendme message, A sends the article to B.

      This protocol can be used to cut down on redundant traffic
      between  sites.  It is optional and should be used only if
      the particular situation makes it worthwhile.  Frequently,
      the  outcome    is  that,  since  most original messages are
      short, and since there is a high overhead to start sending
      a  new  message  with  UUCP,    it costs as much to send the
      Ihave as it would cost to send the article itself.

      One possible solution to this overhead problem is to batch
      requests.   Several  message    ID's  may  be  announced  or
      requested in one message.  If no message ID's  are  listed
      in  the control message, the body of the message should be
      scanned for message ID's, one per line.

      3.3  Newgroup               Newgroup               Newgroup               Newgroup

           newgroup <groupname>

      This control message creates a new newsgroup with the name
      given.  Since no articles may be posted or forwarded until
      a newsgroup is created, this message is required before  a
      newsgroup  can  be  used.   The  body  of  the  message is
      expected to be a short paragraph describing  the  intended
      use of the newsgroup.

      3.4  Rmgroup               Rmgroup               Rmgroup               Rmgroup

           rmgroup <groupname>

      This message removes a  newsgroup  with  the    given  name.
      Since  the  newsgroup  is  removed  from every site on the
      network, this  command  should  be  used  carefully  by  a
      responsible administrator.

      3.5  Sendsys               Sendsys               Sendsys               Sendsys

           sendsys (no arguments)

      The  ``sys''  file,  listing  all  neighbors   and   which
      newsgroups  are  sent  to each neighbor, will be mailed to
      the author of the control message (Reply-to,  if  present,
      otherwise  From).   This  information is considered public
      information, and it is  a  requirement  of  membership  in
      USENET  that    this  information  be  provided  on request,
      either automatically in response to this control  message,
      or  manually,  by mailing the requested information to the











                    - 13 -



      author of the message.  This information is used  to    keep
      the  map  of    USENET    up  to    date, and to determine where
      netnews is sent.

      The format of the file mailed back to the author should be
      the same as that of the ``sys'' file.  This format has one
      line per neighboring site (plus one  line  for  the  local
      site),  containing four colon separated fields.  The first
      field has the site name of the neighbor, the second  field
      has  a newsgroup pattern describing the newsgroups sent to
      the neighbor.  The third and fourth fields are not defined
      by this standard.  A sample response:

           From cbosgd!mark  Sun Mar 27 20:39:37 1983
           Subject: response to your sendsys request
           To: [e-mail]

           Responding-System: cbosgd.UUCP
           cbosgd:osg,cb,btl,bell,net,fa,to,test
           ucbvax:net,fa,to.ucbvax:L:
           cbosg:net,fa,bell,btl,cb,osg,to.cbosg:F:/usr/spool/outnews/cbosg
           cbosgb:osg,to.cbosgb:F:/usr/spool/outnews/cbosgb
           sescent:net,fa,bell,btl,cb,to.sescent:F:/usr/spool/outnews/sescent
           npois:net,fa,bell,btl,ug,to.npois:F:/usr/spool/outnews/npois
           mhuxi:net,fa,bell,btl,ug,to.mhuxi:F:/usr/spool/outnews/mhuxi

      3.6  Senduuname               Senduuname               Senduuname               Senduuname

           senduuname      (no arguments)

      The ``uuname'' program is run, and the output is mailed to
      the  author  of the control message (Reply-to, if present,
      otherwise From).  This program lists all uucp neighbors of
      the  local site.  This information is used to make maps of
      the UUCP network.  The sys file is not  the  same  as  the                                             ___
      UUCP     L.sys     file.     The  L.sys  file  should  never  be                                                           _____
      transmitted to another party without the  consent  of  the
      sites whose passwords are listed therein.

      It is optional for a site  to  provide  this    information.
      Some    reply  should  be  made to the author of the control
      message, so that a transmission error won't be blamed.  It
      is  also  permissible for a site to run the uuname program
      (or in some other way determine the  uucp  neighbors)  and
      edit    the output, either automatically or manually, before
      mailing the reply back to the  author.   The    file  should
      contain  one    site  per line, beginning with the uucp site
      name.  Additional information may be    included,  separated
      from the site name by a blank or tab.  The phone number or
      password for the site should NOT be included, as the reply
      is  considered  to  be  in the public domain.  (The uuname











                    - 14 -



      program will send only the site name and  not  the  entire
      contents  of    the  L.sys  file,  thus,  phone  numbers and
      passwords are not transmitted.)

      The purpose of this message is to  generate  and  maintain
      UUCP mail routing maps.  Thus, connections over which mail
      can be sent using the site!user syntax should be included,
      regardless  of whether the link is actually a UUCP link at
      the physical level.  If a mail router should    use  it,  it
      should   be  included.   Since  all  information  sent  in
      response to this message is optional, sites  are  free  to
      edit    the  list,  deleting secret or private links they do
      not wish to publicise.

      3.7  Version               Version               Version               Version

           version (no arguments)

      The name and version of the software running on the  local
      system  is  to be mailed back to the author of the article
      (Reply-to if present, otherwise From).


      4.  Transmission Methods              Transmission Methods              Transmission Methods              Transmission Methods

      USENET is not a physical network,  but  rather  a  logical
      network  resting  on    top  of  several  existing  physical
      networks.  These networks include, but are not limited to,
      UUCP,  the ARPANET, an Ethernet, the BLICN network, an NSC
      Hyperchannel, and a Berknet.    What is  important  is    that
      two  neighboring systems on USENET have some method to get
      a new article, in the format listed here, from one  system
      to  the other, and once on the receiving system, processed
      by the netnews software on that system.  (On UNIX systems,
      this    usually  means    the ``rnews'' program being run with
      the article on the standard input.)

      It is not  a    requirement  that  USENET  sites  have    mail
      systems  capable  of    understanding the ARPA Internet mail
      syntax, but  it  is  strongly  recommended.    Since  From,
      Reply-To,  and  Sender  lines  use  the  Internet  syntax,
      replies  will  be  difficult    or  impossible    without   an
      internet  mailer.   A  site without an internet mailer can
      attempt to use the Path header line for replies, but    this
      field  is not guaranteed to be a working path for replies.
      In any event,  any  site  generating    or  forwarding    news
      messages must have an internet address that allows them to
      receive mail from sites with internet  mailers,  and    they
      must include their internet address on their From line.













                    - 15 -



      4.1  Remote Execution               Remote Execution               Remote Execution               Remote Execution

      Some networks permit direct remote command execution.   On
      these  networks,  news  may  be  forwarded by spooling the
      rnews command with the article on the standard input.  For
      example,  if    the remote system is called ``remote'', news
      would be sent over a UUCP link with the  command  ``uux  -
      remote!rnews'',  and on a Berknet, ``net -mremote rnews''.
      It is important that the article be sent  via  a  reliable
      mechansim, normally involving the possibility of spooling,
      rather than direct real-time remote  execution.   This  is
      because,  if the remote system is down, a direct execution
      command  will  fail,    and  the  article  will   never   be
      delivered.   If the article is spooled, it will eventually
      be delivered when both systems are up.

      4.2  Transfer by Mail               Transfer by Mail               Transfer by Mail               Transfer by Mail

      On some systems, direct remote spooled  execution  is  not
      possible.   However, most systems support electronic mail,
      and a news article can be sent as mail.  One    approach  is
      to  send  a  mail  message  which is identical to the news
      message: the mail headers are the news  headers,  and  the
      mail    body  is the news body.  By convention, this mail is
      sent to the user ``newsmail'' on the remote machine.

      One problem with  this  method  is  that  it    may  not  be
      possible to convince the mail system that the From line of
      the message is valid, since the mail message was generated
      by  a program on a system different from the source of the
      news article.  Another  problem  is  that  error  messages
      caused  by  the  mail  transmission  would  be sent to the
      originator of the news article, who has  no  control    over
      news    transmission  between two cooperating hosts and does
      not know who    to  contact.   Transmission  error  messages
      should  be directed to a responsible contact person on the
      sending machine.

      A solution to this problem  is  to  encapsulate  the    news
      article  into a mail message, such that the entire article
      (headers and body) are  part  of  the  body  of  the  mail
      message.  The convention here is that such mail is sent to
      user ``rnews'' on the remote system.  A mail message  body
      is  generated  by prepending the letter ``N'' to each line
      of the news article,    and  then  attaching  whatever    mail
      headers  are convenient to generate.    The N's are attached
      to prevent any special lines    in  the  news  article    from
      interfering  with  mail  transmission,  and to prevent any
      extra lines inserted by the mailer (headers, blank  lines,
      etc.)  from  becoming part of the news article.  A program
      on the  receiving  machine  receives    mail  to  ``rnews'',











                    - 16 -



      extracting  the  article itself and invoking the ``rnews''
      program.  An example in this format might look like this:

           Date: Monday, 3-Jan-83 08:33:47 MST
           From: [e-mail]
           Subject: network news article
           To: [e-mail]

           NRelay-Version: B 2.10  2/13/83 cbosgd.UUCP
           NPosting-Version: B 2.9 6/21/82 sask.UUCP
           NPath: cbosgd!mhuxj!harpo!utah-cs!sask!derek
           NFrom: [e-mail] (Derek Andrew)
           NNewsgroups: net.test
           NSubject: necessary test
           NMessage-ID: <[e-mail]>
           NDate: Monday, 3-Jan-83 00:59:15 MST
           N
           NThis really is a test.    If anyone out there more than 6
           Nhops away would kindly confirm this note I would
           Nappreciate it.    We suspect that our news postings
           Nare not getting out into the world.
           N


      Using mail solves the spooling problem,  since  mail    must
      always  be  spooled  if  the    destination  host  is  down.
      However, it adds more overhead to the transmission process
      (to  encapsulate  and  extract  the  article) and makes it
      harder for software to give different priorities  to    news
      and mail.

      4.3  Batching               Batching               Batching               Batching

      Since news articles are usually short, and since  a  large
      number  of  messages are often sent between two sites in a
      day, it may make sense to batch  news  articles.   Several
      articles  can  be  combined  into one large article, using
      conventions agreed upon in advance by the two sites.     One
      such    batching  scheme is described here; its use is still
      considered experimental.

      News articles are combined into a script, separated  by  a
      header of the form:

           ##! rnews 1234

      where 1234 is the length, in bytes, of the article.    Each
      such    line  is followed by an article containing the given
      number of bytes.  (The newline at the end of each line  of
      the  article    is counted as one byte, for purposes of this
      count, even if it is stored as CRLF.) For example, a batch











                    - 17 -



      of articles might look like this:

        #! rnews 374
        Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
        Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
        Path: cbosgd!mhuxj!mhuxt!eagle!jerry
        From: [e-mail] (Jerry Schwarz)
        Newsgroups: net.general
        Subject: Usenet Etiquette -- Please Read
        Message-ID: <[e-mail]>
        Date: Friday, 19-Nov-82 16:14:55 EST

        Here is an important message about USENET Etiquette.
        #! rnews 378
        Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
        Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
        Path: cbosgd!mhuxj!mhuxt!eagle!jerry
        From: [e-mail] (Jerry Schwarz)
        Newsgroups: net.followup
        Subject: Notes on Etiquette article
        Message-ID: <[e-mail]>
        Date: Friday, 19-Nov-82 17:24:12 EST

        There was something I forgot to mention in the last message.

      Batched news is recognized because the first character  in
      the  message    is ``#''.  The message is then passed to the
      unbatcher for interpretation.


      5.  The News Propagation Algorithm              The News Propagation Algorithm              The News Propagation Algorithm              The News Propagation Algorithm

      This section describes the overall scheme  of  USENET  and
      the algorithm followed by sites in propagating news to the
      entire  network.   Since  all  sites     are   affected   by
      incorrectly  formatted articles and by propagation errors,
      it is important for the method to be standardized.

      USENET is a directed graph.  Each node in the graph  is  a
      host    computer,  each  arc  in the graph is a transmission
      path from one host to another host.  Each arc is  labelled
      with    a  newsgroup  pattern,    specifying  which  newsgroup
      classes are forwarded along  that  link.   Most  arcs  are
      bidirectional,  that    is,  if  site  A  sends  a  class of
      newsgroups to site B, then site B usually sends  the    same
      class  of  newsgroups to site A.  This bidirectionality is
      not, however, required.

      USENET is made up of many subnetworks.  Each subnet has  a
      name,  such  as  ``net''  or  ``btl''.  The special subnet
      ``net'' is defined to be USENET, although the union of all











                    - 18 -



      subnets may be a superset of USENET (because of sites that
      get local newsgroup classes but do not get net.all).    Each
      subnet  is  a connected graph, that is, a path exists from
      every  node  to  every  other  node  in  the    subnet.   In
      addition,  the  entire graph is (theoretically) connected.
      (In practice, some political  considerations  have  caused
      some sites to be unable to post articles reaching the rest
      of the network.)

      An  article  is  posted  on  one  machine  to  a  list  of
      newsgroups.     That    machine  accepts  it  locally,    then
      forwards it to all its neighbors that are interested in at
      least one of the newsgroups of the message.  (Site A deems
      site    B  to  be  ``interested''  in  a  newsgroup  if  the
      newsgroup  matches  the  pattern  on    the arc from A to B.
      This pattern is stored in a file on the  A  machine.)  The
      sites  receiving  the  incoming article examine it to make
      sure they really want the article, accept it locally,  and
      then    in  turn forward the article to all their interested                                                    _____
      neighbors.   This  process  continues  until    the   entire
      network has seen the article.

      An important part of the algorithm is  the  prevention  of
      loops.   The    above  process would cause a message to loop
      along a cycle forever.  In particular, when site  A  sends
      an  article to site B, site B will send it back to site A,
      which will send it to site B, and so on.  One solution  to
      this    is  the history mechanism.  Each site keeps track of
      all articles    it  has  seen  (by  their  message  ID)  and
      whenever an article comes in that it has already seen, the
      incoming article is discarded immediately.  This  solution
      is   sufficient   to     prevent   loops,   but   additional
      optimizations can be made to    avoid  sending    articles  to
      sites that will simply throw them away.

      One optimization is that an article should never  be    sent
      to  a machine listed in the Path line of the header.    When
      a machine name is in the Path line, the message  is  known
      to  have passed through the machine.    Another optimization
      is that, if the article originated on site A, then site  A
      has    already  seen  the  article.   (Origination  can  be
      determined by the Posting-Version line.)

      Thus, if an article is posted to  newsgroup  ``net.misc'',
      it  will match the pattern ``net.all'' (where ``all'' is a
      metasymbol that matches any string), and will be forwarded
      to  all  sites that subscribe to net.all (as determined by
      what their neighbors send them).  These sites make up  the
      ``net''  subnetwork.  An article posted to ``btl.general''
      will reach all sites receiving ``btl.all'', but  will  not
      reach  sites    that do not get ``btl.all''.  In effect, the











                    - 19 -



      articles  reaches  the  ``btl''  subnetwork.   An  article
      posted  to newsgroups ``net.micro,btl.general'' will reach
      all sites subscribing to either of the two classes.


























































============

From schein  Thu Jun  9 14:36:35 1988 remote from cbmvax
Received: by cbmvax.UUCP (1.2/UUCP-Project/Commodore 12/21/87))
    id AA14116; Thu, 9 Jun 88 14:36:35 edt
Date: Thu, 9 Jun 88 14:36:35 edt
From: cbmvax!schein (Dan Schein CATS)
Message-Id: <[e-mail]>
To: heimat!sysop
Subject: How to UseNet


                How to Use USENET Effectively


                     Matt Bishop
          Research Institute for Advanced Computer Science
                   Mail Stop 230-5
                  NASA Ames Research Center

                  Moffett Field, CA  94035



      1.  Introduction

           USENET  is  a  worldwide  bulletin  board  system  in  which
      thousands of computers pass articles back and forth.    Of necessi-
      ty, customs have sprung  up  enabling  very  diverse    people    and
      groups  to  communicate  peaceably  and effectively using USENET.
      These customs are for the most part written,    but  are  scattered
      over    several  documents  that  can  be difficult to find; in any
      case, even if a new user can find  all  the  documents,  he  most
      likely  will    have  neither  the time nor the inclination to read
      them all.  This document is intended to collect all these conven-
      tions  into  one  place,  thereby making it easy for new users to
      learn about the world of USENET.  (Old-timers, too, will  benefit
      from reading this.)

           You should read this document and understand  it  thoroughly
      before  you even think about posting anything.  If you have ques-
      tions, please ask your USENET administrator (who can  usually  be
      reached by sending mail to usenet) or a more knowledgeable USENET
      user.  Believe me, you will save yourself a lot of grief.

           The mechanics of posting an article to USENET are  explained
      in Mark Horton's excellent paper How to Read the Network News; if
      you have not read that yet, stop here and do so.  A lot  of  what
      follows  depends on your knowing (at least vaguely) the mechanics
      of posting news.

           Before we discuss these customs, we ought  to  look  at    the
      history  of  USENET, what it is today, and why we need these con-
      ventions.

      2.  All About USENET

           USENET began on a  set  of  computers  in  North  Carolina's
      Research  Triangle.    The  programs  involved (known as "netnews"
      then, and "A news" now)  exchanged  messages;  it  was  a  small,
      multi-computer  bulletin  board system.  As time passed, adminis-
      trators of other systems began to connect their computers to this
      bulletin board system.  The network grew.  Then, at Berkeley, the


      News Version B 2.11                   October 19, 1986









      news programs were rewritten (this version  became  known  as  "B
      news")  and  the  format  changed  to  conform  to ARPA standards
      (again, this became the "B protocol for news".*) This version  of
      news    was very widely distributed, and at this point USENET began
      to take on its current shape.

           USENET is a logical network (as opposed to a  physical  net-
      work.)  It  is also a very amorphous network, in that there is no
      central administration or controlling site.  There is not even an
      official list of members, although there is a very complete unof-
      ficial one.  A site gets access to USENET by finding    some  other
      site    already  on USENET that it can connect to and exchange news
      articles.  So long as this second site (called a neighbor of  the
      first site) remains willing and able to pass articles to and from
      the first site, the first site is on USENET.    A site    leaves    the
      USENET  only    when no one is willing or able to pass articles to,
      or accept articles from, it.

           As a result, USENET has no equivalent of a "sysop"  or  cen-
      tral    authority controlling the bulletin board.  What little con-
      trol is exercised is wielded by the person at each  site  who  is
      responsible  for  maintaining the USENET connections (this person
      is called the "USENET administrator.") Because  most  USENET  ad-
      ministrators are (relatively) new to USENET, and because adminis-
      tering USENET locally involves a great deal of work, most  USENET
      administrators  tend    to  follow  the lead of other, more experi-
      enced, administrators (often known somewhat irreverently as  "net
      gurus.") This is not an abdication of responsibility, but a means
      of keeping the amount of work little enough so  it  can  be  done
      without  interfering    with  the local USENET administrator's job.
      An example of this is the list  of  currently  active  newsgroups
      circulated  every month or so.  It is not "official" - no one has
      that authority - but as the maintainer is  doing  the  work  that
      every  other    USENET administrator would have to do otherwise, it
      is accepted as a valid list.    If the maintainer changes the  list
      in  a  way  another USENET administrator finds unacceptable, that
      administrator can simply ignore  the    list.    (Incidentally,  the
      "net  gurus"  became  known as such because of the work they have
      contributed to USENET.  Their experience is a  valuable  resource
      for each USENET administrator.)

           Because the USENET has grown so wildly, a number of problems
      have    appeared.  One of these problems is technical, and a number
      of the conventions this document describes spring  from  attempts
      to keep this problem under control.

           The technical problem arises due to the transport  mechanism
      used    by most USENET sites.  Most computers on USENET do not have
      access to large-area networks like ARPANET.  As a result the only

      __________

      * See Standard for Interchange of USENET Messages for a
        description of the two formats.


      News Version B 2.11                   October 19, 1986









      viable transport mechanism these sites can use is a set  of  pro-
      grams collectively known as UUCP and which communicate over dial-
      up telephone lines.  Initially, news programs generated one  UUCP
      command  per    article.   With  the  explosion  of the USENET, the
      number of articles simply swamped many sites; phone  lines  would
      be  tied up all day transmitting news, and many articles would be
      processed at the same time, slowing down  the  computers  notice-
      ably.

           The solution was to batch messages.  This way, many articles
      are  sent  via  UUCP with one command, and the command on the re-
      ceiving machine would split  the  file  into    separate  articles,
      which could then be processed individually.  While this increased
      the size of the files being sent, it cut down on  the  number  of
      UUCP    commands sent, and since sending a command involves quite a
      bit of overhead, this decreased the duration of phone calls,    and
      to a lesser degree the load on the computer.    At some sites, such
      as Purdue, this was not quite enough, so a simple spooler was im-
      plemented to process the individual articles one at a time.  This
      reduced the system load to a very acceptable amount.

           However, the problem has not gone away by any means.  In one
      sense  it  has  become  worse; as more articles are posted to the
      network, phone costs and system loads averages increase, and sys-
      tem  administrators  require USENET administrators to cut back or
      eliminate newsgroups and to transmit news only  at  night  (which
      means  long propagation delays).  In short, everyone who has any-
      thing to do with administering any USENET site is very  concerned
      about the future of USENET, both in general and at his own site.

           Many of the rules you will read address this  concern.    The
      fear    that  USENET may collapse is not a bogeyman, but very real.
      We hope it will not collapse, and the rules  below  outline  some
      ways    to prevent problems and increase the likelihood that enough
      sites will remain on USENET to keep it alive.  There is  no  cen-
      tral authority that can force you to follow them, but by doing so
      you will help keep USENET a valuable    resource  to  the  computer
      community.

      3.  Deciding to Post

           Before you decide to post an article, you should consider  a
      few things.

      3.1.    Do not repeat postings

           This applies even if you did not post  the  information    the
      first  time around.  If you know the answer to a question someone
      asked, first read the follow-ups, and if you have something  more
      to  contribute, mail it to the questioner; if you think it should
      be seen by others, ask the questioner to summarize the answers he
      receives in a subsequent article.  One of the biggest problems on
      USENET is that many copies of the same answer to a  simple  ques-
      tion are posted.


      News Version B 2.11                   October 19, 1986









           If you want to repost something because you believe  it    did
      not  get to other USENET sites due to transmission problems (this
      happens sometimes, but a lot less often than commonly  believed),
      do  some  checking  before  you  repost.  If you have a friend at
      another USENET site, call him and ask if the article made  it  to
      his site.  Ask your USENET administrator if he knows of any prob-
      lems in the USENET; there are special newsgroups to which  USENET
      administrators  subscribe  in  which problems are reported, or he
      can contact his counterparts at other sites for information.    Fi-
      nally,  if you decide you must repost it, indicate in the article
      subject that it is a reposting, and say why you are reposting  it
      (if you don't, you'll undoubtedly get some very nasty mail.)

           Reposting announcements of products or  services  is  flatly
      forbidden.   Doing  so  may convince other sites to turn off your
      USENET access.

           When school starts, hoards of new  users  descend  upon    the
      USENET  asking  questions.   Many  of  these    questions have been
      asked, and answered, literally thousands of  times  since  USENET
      began.   The    most  common of these questions, and their answers,
      have been collected in the hope that the new users will read them
      and  not  re-post  the  same questions.  So, if you want to ask a
      question, check Appendix A (Answers  to  Frequently  Asked  Ques-
      tions)  to  be sure it isn't one that has been asked and answered
      literally hundreds  of  times  before  you  started  reading    the
      USENET.

      3.2.    Do not post anything when upset, angry, or intoxicated

           Posting an article is a lot like driving a car - you have to
      be  in  control of yourself.    Postings which begin "Jane, you ig-
      norant slut, ..." are very definitely considered in poor  taste*.
      Unfortunately, they are also far too common.

           The psychology of this is interesting.  One  popular  belief
      is that since we interact with USENET via computers, we all often
      forget that a computer did not do the posting; a  human  did.   A
      contributing    factor is that you don't have to look the target of
      abuse in the eye when you post  an  abusive  message;  eye-to-eye
      contact  has    an amazing effect on inhibiting obnoxious behavior.
      As a result, discussions on the USENET often    degenerate  into  a
      catfight far more readily than would a face-to-face discussion.

           Before you post an article, think a minute;  decide  whether
      or not you are upset, angry, or high.  If you are, wait until you
      calm down (or come down) before deciding to post something.  Then
      think  about whether or not you really want to post it.  You will
      be amazed what waiting a day or even a few hours can do for  your
      perspective.


      __________
      * Unless you are critiquing Saturday Night Live.


      News Version B 2.11                   October 19, 1986









           Bear in mind that shouting hasn't convinced anyone  of  any-
      thing since the days of Charlemagne, and being abusive makes peo-
      ple hold even more tenaciously to their ideas or opinions.   Gen-
      tleness,  courtesy,  and  eloquence  are far more persuasive; not
      only do they indicate you have enough confidence in your words to
      allow them to speak for you, but also they indicate a respect for
      your audience.  This in turn makes it easier for your audience to
      like    or  respect you - and people tend to be far more interested
      in, and receptive to, arguments advanced by those  they  like  or
      respect  than by writers who are abusive.  Finally, remember that
      some discussions or situations simply cannot    be  resolved.    Be-
      cause people are different, agreed-upon facts often lead to wild-
      ly different feelings and  conclusions.   These  differences    are
      what    makes life so wonderful; were we all alike, the world would
      be a very boring place.  So, don't get frantic; relax  and  enjoy
      the discussion.  Who knows, you might even learn something!

      3.3.    Be sure your posting is appropriate to USENET

           Some things are inappropriate to post to USENET.  Discussing
      whether  or not some other discussion is appropriate, or if it is
      in the right newsgroup, is an example.   Invariably,    the  "meta-
      discussion"  generates  so  many  articles that the discussion is
      simply overwhelmed and vanishes; but the meta-discussion  lingers
      on  for  several weeks, driving most of the readers of that news-
      group out of their collective minds.    Help preserve the sanity of
      your fellow USENET readers by mailing such comments to the people
      involved, rather than posting them.

           Another example of inappropriate postings  is  the  infamous
      "spelling  flame."  Every few months someone takes another poster
      to task for poor spelling or grammar.  Soon,    everyone  jumps  on
      the  bandwagon, tearing apart one another's postings for such er-
      rors.  To put it mildly, this angers almost everyone involved for
      no  real  reason.  Please remember that we all make mistakes, and
      there are a lot of people for whom English is a second  language.
      So,  try to keep your spelling and grammar comments to yourself -
      but if you find you simply cannot, mail them to the poster rather
      than posting them.

           Far more insidious are requests similar to "How can I splice
      into    the local cable TV transmission line?" Posting to USENET is
      akin to publishing, so don't ask for or post instructions on  how
      to do something illegal.  And please don't quote the First Amend-
      ment, or the laws allowing freedom of  speech  in  your  country;
      while the posting programs will not stop you, the aftermath could
      be very unpleasant - lawsuits and court trials usually  are,    and
      the  USENET  would certainly collapse as sites dropped from it to
      protect themselves from legal liability.  You wouldn't want  that
      on your conscience, would you?  Of course not.

           Related to this is the next rule.




      News Version B 2.11                   October 19, 1986









      3.4.    Do not post other people's work without permission

           Posting something to USENET puts it in the public domain for
      all practical purposes.  So, be careful about posting things like
      UNIX*-related material (specifically source code) or company  do-
      cuments;  consider  licensing and nondisclosure agreements first.
      Some people regard the posting of  "diffs" based on licensed code
      to be a suitable compromise, as they are only useful to those who
      have the base code already.

           Copyrighted works  are  a  separate  problem.   Both  United
      States  and  international law provide protection for copyrighted
      works; other than short extracts for purposes of  criticism,    you
      cannot  copy    a copyrighted work in whole or in part without per-
      mission of the copyright holder (who may, or may not, be the  au-
      thor.)  Without this protection, artists could not make any money
      and hence would have limited incentive  to  make  the  fruits  of
      their  art  available at all.  Posting a copyrighted work without
      permission is theft, even though the property stolen is not  tan-
      gible in most cases.    Hence, posting movie and book reviews, song
      lyrics, or anything else which is copyrighted without the permis-
      sion    of  the  copyright holder, could cause you personally, your
      company, or the USENET itself to  be    held  liable  for  damages.
      Please  be  very  careful that you obey the law when posting such
      material!

      3.5.    Don't forget that opinions are those of the poster and  not
      his employer.

           Every so often, someone will post a particularly  disgusting
      article,  and  a number of responses will ask if all employees of
      the original poster's company share his (revolting)  opinion,  or
      suggest  that  action  be  taken  against  that  company.  Please
      remember that all opinions or statements in articles    are  to  be
      attributed  to  the poster only, and in particular, do not neces-
      sarily represent the opinions of the poster's employer, the owner
      of  the  computer  on which the article originated, or anyone in-
      volved with any aspect of USENET - and consequently the responsi-
      bility  for  any USENET message rests with the poster and with no
      one else.  The appropriate response is not to attack the  company
      or its other employees; let the poster know what you think of his
      posting via mail.  If the postings continue,    take  advantage  of
      the news software's presenting you with the author's name and the
      subject line and then asking if you  want  to  see  the  article;
      start  looking  for the poster's name or the offensive subject in
      the articles presented to you and skip them. If  you    really    get
      offended, you can unsubscribe from a newsgroup.

           Part of the price of freedom  is  allowing  others  to  make
      fools  of themselves.  You wouldn't like to be censored, so don't
      advocate censorship of others.  No one is forcing you to read the

      __________
      *UNIX is a registered trademark of AT&T.


      News Version B 2.11                   October 19, 1986









      postings.

           In some countries, posting or receiving certain types of ar-
      ticles  may  be  a  criminal offense.  As a result, certain news-
      groups which circulate freely within the United States may not be
      circulated in other nations without risking civil or criminal li-
      abilities.  In this case, the appropriate  action  for  sites  in
      that    country is neither to accept nor to transmit the newsgroup.
      No site is ever forced to accept or pass on any newsgroup.

      4.  Where to Post

           The various newsgroups and distributions have various  rules
      associated  with  their  use.   This    section will describe these
      rules and offer suggestions on which newsgroups to post your mes-
      sage.

      4.1.    Keep the distribution as limited as possible

           A basic principle of posting is to keep the distribution  of
      your    article  as  limited as possible.  Like our modern society,
      USENET is suffering from both an information glut and information
      pollution.   It  is widely believed that the USENET will cease to
      function unless we are able to cut down the quantity of articles.
      One  step  in  this  direction is not to post something to places
      where it will be worthless.  For example, if you live in  Hacken-
      sack,  New  Jersey, the probability of anyone in Korea wanting to
      buy your 1972 Toyota is about as close to zero as  you  can  get.
      So confine your posting to the New Jersey area.

           To do this, you can either post to a local group, or post to
      a  net-wide  group  and use the distribution feature to limit how
      widely your article will go.    When you give your posting  program
      (usually postnews(1)) a distribution, you are (in essence) saying
      that machines which do not recognize that distribution should not
      get  the  article.   (Think of it as a subgroup based on locality
      and you'll get the idea.) For example, if you are posting in  the
      San Francisco Bay Area, and you post your article to rec.auto but
      give ba as the distribution, the article will not be sent  beyond
      the  San  Francisco Bay Area (to which the ba distribution is lo-
      cal) even though you put it in a  net-wide  newsgroup.   Had    you
      given  the distribution as ca (the California distribution), your
      article would have been sent to all Californian sites on  USENET.
      Had  you given the distribution as world, your article would have
      been sent to all sites on USENET.

      4.2.    Do not post the same article twice to different groups

           If you have an article that you want to post  to  more  than
      one  group, post to both at the same time.  Newer versions of the
      news software will show an article only once    regardless  of    how
      many    newsgroups  it appears in.  But if you post it once to each
      different group, all versions of news software will show it  once
      for  each  newsgroup.   This    angers    a  lot of people and wastes


      News Version B 2.11                   October 19, 1986









      everybody's time.

      4.3.    Do not post to moderated newsgroups.

           You may not post directly to certain newsgroups; you  cannot
      post    to  some  at all.  Newer versions of the news software will
      inform you when either of these  restrictions  apply,  but  older
      versions of news software will not.

           If you want to have the    appropriate  moderator    post  some-
      thing,  mail    it  to    the moderator.    (If you do not know the ad-
      dress,  ask  your  USENET  administrator.   In  some    cases,    the
      software  will automatically mail, rather than post, your article
      to the moderator.)

      4.4.    Ask someone if you can't figure out where to post your  ar-
      ticle

           If you cannot figure out where to post  something,  look  in
      news.announce.newusers  for the list of active newsgroups.  (This
      is posted biweekly.  If you can't find it, look at  the  list  in
      How  to Read the Network News; but be aware that list is undoubt-
      edly out of date already.) If your article does not seem  to    fit
      in  any  of the listed groups, post it to misc.misc or don't post
      it.

           If you still are not sure which newsgroup to post your arti-
      cle  to,  ask  an  old-timer.  If your site doesn't have any old-
      timers (or none of  the  old-timers  will  admit  to  being  old-
      timers), contact any of the following people:

           Gene Spafford ([e-mail], [e-mail])
           Mark Horton ([e-mail])
           Rick Adams ([e-mail], [e-mail])
           Chuq Von Rospach ([e-mail])
           Matt Bishop ([e-mail], [e-mail])

      We will be happy to help you.  But, please, do not post the arti-
      cle to the net before you ask us!

      4.5.    Be sure there is a consensus before creating  a  new  news-
      group

           Creating a new newsgroup is, in general, a  very  bad  idea.
      Currently,  there  are  so  many  articles  being posted that the
      USENET is in danger of collapse as site  after  site    decides  to
      cease  to  accept  and  retransmit certain newsgroups.  Moreover,
      there is no established procedure for deleting  a  newsgroup,  so
      once    created, newsgroups tend to stay around.  They also tend to
      encourage people to think up new newsgroups, and  the  cycle    re-
      peats.  Try to avoid thinking up new newsgroups.

           If, however, you believe a new group should be  created,  be
      sure    you  have  a  consensus  that the group is needed (either a


      News Version B 2.11                   October 19, 1986









      mailing list has enough traffic and readers to justify turning it
      into    a newsgroup, or a discussion in a current newsgroup becomes
      so large for a period of time long enough to warrant splitting it
      into    a newsgroup.) Then post an article to news.group as well as
      any other groups related to your proposed new group, and  discuss
      the  topics  you are proposing be covered in your new group, what
      it should be called, whether it is really needed, and  so  forth.
      Try  to resolve all objections, and take into account all sugges-
      tions and comments; finally, have everyone mail you  a  "yes"  or
      "no"  vote on whether the group should be created.  Try to get at
      least 40 or 50 "yes" votes before creating the group; if you want
      to be safe, get around 100.

      4.6.    Watch out for newsgroups which    have  special  rules  about
      posting

           Some newsgroups have special rules.  This section summarizes
      them.

      rec.arts.books      Do not post anything revealing a    plot  or  a
                  plot twist without putting the word "spoiler"
                  somewhere in the "Subject" field.  This  will
                  let  those who do not wish to have a surprise
                  spoiled skip the article.

      rec.humor          If you want to post an offensive    joke  (this
                  includes    racial, religious, sexual, and sca-
                  tological humor, among  other  kinds)  rotate
                  it.   (If  you  do  not know what this means,
                  look in the section Writing Your Posting.)

      rec.arts.movies     Do not post anything revealing a    plot  or  a
                  plot twist without putting the word "spoiler"
                  in the "Subject" field.  This will let  those
                  who  do  not  wish to have a surprise spoiled
                  skip the article.

      news.group          Discussions about whether or  not  to  create
                  new  groups,  and what to name them, go here.
                  Please mail your votes to the proposer; don't
                  post them.

      comp.sources          Source code postings  go    here.    Discussions
                  are not allowed.    Do not post bug fixes here.

      comp.sources.bugs   Bug reports and bug fixes to  sources  posted
                  in comp.sources go here.

      comp.sources.wanted Requests for sources go here.

      misc.test          Use the smallest distribution  possible.     In
                  the  body  of  the  message, say what you are
                  testing.



      News Version B 2.11                   October 19, 1986









      misc.wanted          Requests for things other than source code go
                  here.   Please  use the smallest distribution
                  possible.  Post offers here, too.

      5.  Writing the Article

           Here are some suggestions to help you communicate effective-
      ly  with others on the USENET.  Perhaps the best advice is not to
      be afraid to consult a book on writing style; two of the best are
      How  to  Write  for the World of Work by Cunningham and Pearsall,
      and Elements of Style by Strunk and White.

      5.1.    Write for your audience

           USENET is an international network, and any article you post
      will be very widely read.  Even more importantly, your future em-
      ployers may be among the readers!  So, try to make a good impres-
      sion.

           A basic principle  of  all  writing  is    to  write  at  your
      readers'  reading  level.   It  is better to go below than above.
      Aiming where "their heads ought to be" may be fine if you  are  a
      college  professor (and a lot of us would dispute even that), but
      it is guaranteed to cause people to ignore your article.  Studies
      have    shown  that  the  average American reads at the fifth grade
      level and the average professional reads  at    the  twelfth  grade
      level.

      5.2.    Be clear and concise

           Remember that you are writing for a very busy audience; your
      readers  will not puzzle over your article.  So be very clear and
      very concise.  Be precise as well;  choose  the  least  ambiguous
      word    you  can,  taking into account the context in which you are
      using the word.  Split your posting into sections and  paragraphs
      as  appropriate.  Use a descriptive title in the "Subject" field,
      and be sure that the title is related to the body of the article.
      If  the  title  is not related, feel free to change it to a title
      that is.

      5.3.    Proofread your article

           This is a matter of courtesy; since you want others to  read
      your article, the least you can do is check that it says what you
      mean in a clear, concise manner.  Check for typographical errors,
      silly  grammar  errors,  and misspellings; if you have a spelling
      checking program, use it.  Also be sure the article  is  easy  to
      read.   Use  white  space - blanks, tabs, and newlines - and both
      upper and lower case letters.  Do not omit the definite and inde-
      finite  articles, either; not only do "a", "an", and "the" make a
      posting much easier to read, their omission can  make  a  posting
      ambiguous.




      News Version B 2.11                   October 19, 1986









      5.4.    Be extra careful with announcements of products or services

           When writing a product or service announcement, bear in mind
      that    others    will be paying most of the telephone bills.  So, if
      you are announcing several things, combine all the  announcements
      into    one  article.  Mark the posting as a product or service an-
      nouncement in the title in the "Subject" field.  Advertising  hy-
      perbole  is  not appropriate here; remember that your audience is
      to a large degree technically literate,  and    your  product  will
      stand or fall on its technical merits.  Be aware that posting ob-
      noxious or inappropriate advertisements is very  serious  and  if
      you  do  it,    you may find your neighbors yanking your USENET ac-
      cess.

      5.5.    Indicate sarcasm and humor

           Remember that people cannot see    you  when  they  read  your
      posting;  hence, all the subtle nuances of body and facial motion
      are hidden.  It can be quite difficult to tell when you are being
      sarcastic  or  humorous.   To  deal with this problem, the USENET
      readers and posters have developed a special sign.  Mark passages
      you  intend to be taken as humorous with the "smiley face", while
      looks like this: ":-)".  (Think of a head facing you lying on its
      right side and look again if you don't understand why that symbol
      was chosen.) As for sarcasm, there is  no  universal    symbol    for
      that    (unless  the sarcasm is meant humorously, in which case use
      the smiley face again.) But mark your passage  so  everyone  will
      realize you are being sarcastic.

      5.6.    Mark postings which spoil surprises

           High on the list of obnoxious messages are those that  spoil
      the  plot of a book or movie by giving away an unexpected detail.
      If you post such an article, please put the word "spoiler" in the
      "Subject"  field  of  your  posting, so people who do not wish to
      have a surprise ruined can skip the article.

      5.7.    Rotate offensive postings

           If you feel you must post a message that may offend  people,
      you  can  take  steps to be sure the message will only be read by
      those who explicitly ask for it to be shown to them.    The  USENET
      convention  is  to encrypt these messages by shifting each letter
      13 characters, so that (for example) "a" becomes "n".   (In  more
      precise  terms,  this  is  a    Caesar    cipher    of shift 13; on the
      USENET, it is called rot13.) When  you  do  this,  put  the  word
      "rot13"  in  the  "Subject" field.  The news reader you are using
      almost certainly has a command to encrypt and decrypt  such  mes-
      sages; if not, use the UNIX command

                   tr a-zA-Z n-za-mN-ZA-M





      News Version B 2.11                   October 19, 1986









      5.8.    The shorter your signature, the better

           Keep signatures concise; 2 or 3 lines  are  usually  plenty.
      Include  your  name  and addresses on any major networks (such as
      ARPANET, BITNET, or CSNET).  This helps people contact you quick-
      ly  and easily, usually more so than by following the return path
      of the article.  Do not include pictures, graphics or clever quo-
      tations that make the signature longer; this is not the appropri-
      ate place for them, and many sites resent paying the phone  bills
      for such signatures.

      6.  Conclusion and Summary

           Here is a list of the rules given above:

           => Deciding to post

            + Do not repeat postings

            + Do not post anything when upset, angry, or intoxicat-
              ed

            + Be sure your posting is appropriate to USENET

            + Do not post other people's work without permission

            + Don't forget that opinions are those  of  the  poster
              and not his company

           => Where to Post

            + Keep the distribution as limited as possible

            + Do not post  the    same  article  twice  to  different
              groups

            + Do not post to news.announce newsgroups

            + Ask someone if you can't figure  out  where  to  post
              your article

            + Be sure there is a consensus before  creating  a    new
              newsgroup

            + Watch out for newsgroups    which  have  special  rules
              about posting

           => Writing the Article

            + Write for your audience

            + Be clear and concise




      News Version B 2.11                   October 19, 1986









            + Proofread your article

            + Be extra careful with announcements  of  products  or
              services

            + Indicate sarcasm and humor

            + Mark postings which spoil surprises

            + Rotate offensive postings

            + The shorter your signature, the better

           The USENET can be a great place    for  us  all.    Sadly,    not
      enough  people  are  following  the  customs that have been esta-
      blished to keep the USENET civilized.  This document was  written
      to  educate  all  users  of the USENET on their responsibilities.
      Let's clean up the USENET, and turn it into a  friendly,  helpful
      community again!

      Acknowledgements: The writing of this document  was  inspired  by
      Chuq    von  Rospach's posting on USENET etiquette, and it draws on
      previous work by Mark Horton, A. Jeff Offutt, Gene Spafford,    and
      Chuq von Rospach.
































      News Version B 2.11                   October 19, 1986









      Appendix A.  Answers to Frequently Asked Questions

      originally from Jerry Schwarz ([e-mail])
      modified by Gene Spafford ([e-mail])
      modified by Matt Bishop ([e-mail])


           This document discusses some items that occur repeatedly  on
      USENET.   They  frequently are submitted by new users, and result
      in many follow-ups, sometimes swamping  groups  for  weeks.    The
      purpose  of  this  note  is  to head off these annoying events by
      answering some questions and warning about the inevitable  conse-
      quence  of  asking  others.  If you don't like my answers, let me
      know and I may include revisions in future versions of this note.

       1. What does UNIX stand for?

          It is not an acronym, but is a pun on "MULTICS." MULTICS is a
          large  operating    system that was being developed shortly be-
          fore UNIX was created.

       2. What is the derivation of "foo" as a filler word?

          The favorite story is that it comes from "fubar" which is  an
          acronym for "fouled up beyond all recognition," which is sup-
          posed to be a military term.  (Various forms of  this  exist,
          "fouled"  usually  being  replaced by a stronger word.) "Foo"
          and "Bar" have the same derivation.

       3. Is a machine at "foo" on the net?

          These questions belong in news.config  if  anywhere,  but  in
          fact  your  best bet is usually to phone somebody at "foo" to
          find out.  If you don't know anybody at "foo" you can  always
          try  calling  and asking for the "computer center." Also, see
          the newsgroup mod.map, where maps of USENET and the UUCP net-
          work are posted regularly.

       4. What does "rc" at the end of files like .newsrc mean?

          According to Dennis Ritchie, "The name rc comes from  RUNCOM,
          which was the rough equivalent on the MIT CTSS system of what
          UNIX calls shell scripts.  Of course, RUNCOM derives from run
          commands."

       5. What do "- (nf)" and "Orphaned Response" in an  item's  title
          mean?

          It means that the item was created by "notefiles," an  alter-
          native  news  handling interface that many people prefer.  If
          you want to find out more you can read the  Notesfile  System
          Reference Manual" or contact uiucdcs!essick.




      News Version B 2.11                   October 19, 1986









       6. What does ":-)" mean?

          This is the net convention for a "smiley face." It means that
          something  is  being said in jest.  If it doesn't look like a
          smiley face to you, flop your head over to the left and  look
          again.

       7. How do I decrypt jokes in rec.humor?

          The standard cipher used in rec.humor in called "rot13." Each
          letter  is replaced by the letter 13 further along in the al-
          phabet (cycling around at the  end).   Most  systems  have  a
          built  in  command  to decrypt such articles; readnews(1) and
          vnews(1) have the D command, rn(1) (another  popular  public-
          domain full screen news reader) has the X or <CONTROL-X> com-
          mands, notes(1) has % or R.  If your system  doesn't  have  a
          program  to encrypt and decrypt these, you can quickly create
          a shell script using tr(1):

                   tr A-Za-z N-ZA-Mn-za-m

          On some versions of UNIX, the tr command    should    be  written
          as:

          tr "[a-m][n-z][A-M][N-Z]" "[n-z][a-m][N-Z][A-M]"

       8. soc.net-people: Is John Doe out there anywhere?

          I suspect that these items are people  looking  for  freshman
          roommates  that  they haven't seen in ten years.  If you have
          some idea where the person is you are usually better off cal-
          ling  the  organization.     For  example, if you call any Bell
          Labs location and request John Doe's number.  They  can  give
          it to you even if he works at a different location.

       9. sci.math: Proofs that 1 = 0.

          Almost everyone has seen one or more of these in high school.
          They  are almost always based on either division by 0 or tak-
          ing the square root of a negative number.

      10. rec.games: Where can I get the source for  empire(6)  or  ro-
          gue(6)?

          You can't.  The authors of these games, as  is  their  right,
          have chosen not to make the sources available.

      11. comp.unix.wizards: How do I remove files with non-ASCII char-
          acters in their names?

          You can try to find a pattern that  uniquely  identifies    the
          file.   This  sometimes  fails  because a peculiarity of some
          shells is that they strip off the high-order bit    of  charac-
          ters  in command lines.  Next, you can try an "rm -i", or "rm


      News Version B 2.11                   October 19, 1986









          -r" (see rm(1).) Finally, you can  mess  around  with  i-node
          numbers and find(1).

      12. comp.unix.wizards: There is a bug in  the  way  UNIX  handles
          protection for programs that run setuid.

          There are indeed problems with the treatment of protection in
          setuid  programs.   When    this is brought up, suggestions for
          changes range from implementing a full  capability  list    ar-
          rangement  to new kernel calls for allowing more control over
          when the effective id is used and when the real id is used to
          control  accesses.  Sooner or later you can expect this to be
          improved.  For now you just have to live with it.

      13. soc.women: What do you think about abortion?

          Although abortion might appear to be an appropriate topic for
          soc.women,  more    heat  than  light  is  generated when it is
          brought up.   Since  the    newsgroup  talk.abortion  has  been
          created,    all  abortion-related  discussion should take place
          there.

      14. soc.singles: What do "MOTOS,"  "MOTSS,",  "MOTAS",  and  "SO"
          stand for?

          Member of the opposite sex, member of the same sex, member of
          the appropriate sex, and significant other, respectively.

      15. How do I use the "Distribution" feature?

          When postnews(1) prompts you for a distribution, it's  asking
          how  widely  distributed    you  want your article.  The set of
          possible replies is different, depending on  where  you  are,
          but  at  Bell  Labs in Murray Hill, New Jersey, possibilities
          include:

               local   local to this machine
               mh      Bell Labs, Murray Hill Branch
               nj      all sites in New Jersey
               btl     All Bell Labs machines
               att     All AT&T machines
               usa     Everywhere in the USA
               na      Everywhere in North America
               world   Everywhere on USENET in the world

          If you hit <RETURN>, you'll get the  default,  which  is  the
          first  part of the newsgroup name.  This default is often not
          appropriate - please take a moment to  think  about  how    far
          away  people  are likely to be interested in what you have to
          say.  Used car ads, housing wanted ads, and things  for  sale
          other  than  specialized    equipment  like computers certainly
          shouldn't be distributed to Europe and Korea, or even to  the
          next state.



      News Version B 2.11                   October 19, 1986









          The newsgroup misc.forsale exists for postings  of  sale    an-
          nouncements.   Its  distribution is limited to North America;
          posters should restrict this distribution  even  further,  if
          possible and appropriate.

      16. Why do some people put funny lines ("bug killers") at the be-
          ginning of their articles?

          Some earlier versions of news had a bug which would drop    the
          first 512 or 1024 bytes of text of certain articles.  The bug
          was triggered whenever the article started with  white  space
          (a  blank  or a tab).  A fix many people adopted was to begin
          their articles with a line containing a character other  than
          white  space.   This  gradually evolved into the habit of in-
          cluding amusing first lines.

          The original bug has since been fixed  in  newer    version  of
          news, and sites running older versions of news have applied a
          patch to prevent articles from losing text.  The "bug-killer"
          lines  are  therefore  probably  no  longer  needed, but they
          linger on.

      17. What is the address or phone number of the "foo" company?

          Try the white and  yellow  pages    of  your  phone  directory,
          first; a sales representative will surely know, and if you're
          a potential customer they will be  who  you're  looking  for.
          Phone  books  for  other    cities are usually available in li-
          braries of any size.  Whoever buys or recommends    things    for
          your  company  will  probably have some buyer's guides or na-
          tional company directories.  Call or visit the reference desk
          of  your    library; they have several company and organization
          directories and many will answer questions like this over the
          phone.   Remember if you only know the city where the company
          is, you can telephone to find out their  full  address  or  a
          dealer.    The network is not a free resource, although it may
          look like that to some people.  It is far better to  spend  a
          few  minutes  of    your  own time researching an answer rather
          than broadcast your laziness and/or ineptness to the net.

















      News Version B 2.11                   October 19, 1986